>From the web page
http://www.frontend.com/accessibility_paper.html

Accessibility & Usability for e-Government

The Frontend.com Accessibility White Paper:
A Primer for Public Sector Officials.


CONTENTS

  * Introduction
  * The Importance of Awareness and Action
  * Disability and Accessibility
  * Testing for Accessibility
  * Frontend e-Government Accessibility Analysis
  * Good Usability is Good Accessibility
  * Summary: What You Need to Do
  * References

Introduction
Government, like business, is going on-line. Ireland is moving
rapidly towards an 'information society' in which e-Government
at national, regional and local levels will play a central role.
The Government's action plan on Implementing the Information
Society in Ireland [1] predicts that:

"In the Internet age, Government websites will become the
gateways for people to conduct their business with Government
and a central feature of public service delivery."

Government web sites will need to be easy for all citizens to
use, including those with a disability, so universal
accessibility is a crucial issue in their design.

This paper is intended as a primer for public sector officials
who are responsible for or otherwise involved in the creation of
web sites. It will tell you:
  * Why you should be concerned about accessibility
  * What targets and legislation apply to you
  * What accessibility is and which disabilities it concerns
  * Some common accessibility problems and their causes
  * What you need to do to develop an accessible web site

As part of this discussion, we present the findings of an
accessibility analysis of three current Irish Government web
sites:
  * Revenue On-Line Services: http://www.revenue.ie/
  * Donegal County Council: www.donegal.ie/dcc
  * Department of the Taoiseach: www.irlgov.ie/taoiseach

We describe some of the problems that disabled people will have
with these sites and how they can be avoided.

The Importance of Accessibility Awareness & Action
There is a growing awareness and concern with accessibility at
all levels of society. This has previously related to the
accessibility of buildings and traditional media. However, this
is now being extended to include the accessibility of online
information and services made available through web sites. In
1999 the Web Publication Group, an Inter-Departmental Group
chaired by the Department of the Taoiseach, was set up to
prepare guidelines and standards for public sector web sites. In
its first report, the group stated as its guiding principle:

"Websites should be designed and operated in accordance with the
needs of users." [2]

Users of public sector web sites are a diverse group, inevitably
including many people with disabilities or impairments. Although
it is difficult to find statistics concerning the number of
disabled people in Ireland, it is likely that the situation is
similar to the U.S. where 8% of the population has visual,
learning, cognitive, auditory or physical dexterity disabilities
severe enough to affect their ability to access the web. [3]
This would equate to about 280,000 disabled users in Ireland.
The Irish Government have recognised this by imposing targets
specifically relating to the accessibility of online public
services. These targets are of importance to all public sector
bodies, since they will each be responsible for the design of
their own web sites and will therefore be accountable for
accessibility.

European Union & Irish Government Targets
Specific accessibility targets have been set at European and
Irish Government levels. The European Union's eEurope
initiative, launched in December 1999, states:

"Public sector web sites and their content in Member States and
in the European Institutions must be designed to be accessible
to ensure that citizens with disabilities can access information
and take full advantage of the potential for e-Government." [4]

The specific actions related to accessibility include, by the
end of 2001:

"Adoption of the Web Accessibility Initiative (WAI) guidelines
for public sector web sites." [4]

and by the end of 2002:

"Review relevant legislation and standards to ensure conformity
with accessibility principles." [4]

The Irish government intends to comply with the eEurope targets
by making all public sector web sites accessible by the end of
2001. The National Disability Authority will be invited to
monitor standards in this area. [5]

Targets will not just apply to national government, however. In
the sphere of local government, the Institute for Design and
Disability (IDD) is carrying out a major campaign entitled
"Citizen 2000" to obtain the agreement of all Local Authorities
in Ireland North and South to adopt the Barcelona Declaration,
which states:

"The Municipal Governments will ensure the access of disabled
persons to information generated by the Community." [6]

To date, Drogheda, Dublin, Limerick, Wexford and Sligo have
adopted the Declaration and are in the process of completing the
formalities of registration. It is envisaged that this project
will take two years to complete.

Legal Action Against Web Sites
Although there is as yet no direct legislation in Ireland
concerning the accessibility of web sites, planned legislation
dealing with discrimination against people with disabilities may
be used as a basis for legal actions against web site providers.
This has already happened in Australia and the U.S.

In a landmark ruling by the Australian Human Rights and Equal
Opportunity Commission, the organisers of the Sydney Olympics
were found to have breached section 24 of the Australian
Disability Discrimination Act (1992) by failing to make their
web site (www.olympics.com) accessible to people with visual
impairments. They were ordered to take immediate action to make
the Olympics and Paralympics sites accessible. Although the
commission is not a court, legally enforceable damages of
AUS$20,000 have been awarded against the organisers. [7]

In the US, the Americans with Disabilities Act (1992) requires
organizations to provide the necessary aids and services to
allow effective communication to people with disabilities. In
the past this has meant that shops, restaurants and other
businesses have had to provide wheelchair ramps and Braille
signs. In November 1999 the National Federation of the Blind
(NFB) lodged a lawsuit against America Online (AOL) claiming
that AOL violated the Act by failing to provide accessible
online services and software. In an out of court agreement, NFB
have agreed to suspend the lawsuit for 12 months, by which time
AOL must make the next version of its software accessible to the
blind, ensure that future AOL products are also accessible and
adopt a company wide accessibility policy. [8]

These actions have shown that existing legislation may be
extended to the online domain, raising the possibility of
similar actions in Ireland using the Disabilities Bill which is
expected to be published late 2001. This bill is designed to set
out the rights of persons with a disability, together with the
means of redress for those whose rights are denied. The
Taoiseach says:

"The preparation of a Disabilities Bill will proceed as quickly
as possible. I would envisage that the Bill will cover areas
such as access to public bodies, the use of telecommunications
services, . and participation in the judicial system. The
providers of basic State services will, from today on, have the
concerns of people with disabilities as part of their core
work." [9]

Whether the Bill will specifically cover online services is not
yet known. However, in the UK Section 21 of the Disability
Discrimination Act (1995) does apply to web service providers
and requires them to make 'reasonable adjustments' to their
services so that disabled people can access them. [10]
Eventually, European governments are likely to follow the U.S.
where Section 508 of the Rehabilitation Act (1998) requires all
Federal agencies to have accessible web sites and intranets by
Spring 2001.

Disability and Accessibility: An Overview

"The key principle underlining accessibility is that web sites
should be easy for everyone to use, including people with a
disability." [2]

Not all people with disabilities have problems using computers
to access the web, but some disabilities can present severe
obstacles. Those most associated with access difficulties are:

  * Visual impairment: Low vision, restricted vision or colour
    blindness
  * Motor skills: Inability to use a keyboard or mouse,
    inability to make fine movements
  * Hearing impairment
  * Cognitive abilities: Reading difficulties, dyslexia or
    memory loss
  * Low grade technology: Slow connections or old versions of
    software

People with these impairments may have difficulty perceiving or
processing some types of information. They may be unable to use
common input devices such as a keyboard or mouse. They may have
to rely on special assistive technologies to enable them to
provide inputs and perceive outputs. For example, blind users
may use a screen reader which is a program that reads the
contents of the screen aloud in a synthetic voice. Users who
have low acuity vision may use a screen magnifier program which
enlarges a selected portion of the screen. People with motor
impairments may require a special keyboard or a pointing device
controlled by a joystick or by head movements.

Typical Accessibility Problems
Although having a disability and having to use assistive
technology inevitably restricts what can be done and at what
speed, it should nevertheless be possible for a disabled person
to access the functionality of a web site. In some cases
designers may have to arrange content or provide alternative
access methods to take advantage of the disabled user's
abilities and the technologies they use. Accessibility problems
occur if designers fail to do this when it is possible.

This paper is not intended to provide an exhaustive coverage of
accessibility problems but to give you an idea of the types of
problems disabled people face. In this section we concentrate on
visual impairment which presents the biggest single barrier to
effective use of the web. We asked a number of visually impaired
computer users to describe the typical problems they encounter
on web sites. Here are some of their answers in their own words
with our explanations of why the problems occur:

- Problem: "Unlabelled Links"
When an image acts as a link and no text description is
provided, a blind user's screen reader cannot describe the link
in a meaningful way. This means the user cannot discern the
purpose of the link, or where it will take them.

To solve this problem, the HTML, the language which is used to
create web pages, includes a construct called the "Alt" tag,
which can be used to provide a text alternative for any non-text
item.

A similar problem arises wherever an image or any other non-text
element is used without an associated alt text description. A
screen reader will be able to read only the image file name
which may typically be something like "photo.gif". This is
meaningless to a blind user who then has no way of knowing how
the image supports or illustrates the text. The user may
therefore feel that they are missing out on important content,
or not know whether they are missing out, eroding their trust in
the site.

- Problem: "Sorting out the text that relates to a link on a
full page"
A screen reader can read out a list of all the links on a page.
This allows the user to quickly scan for useful links without
having to read the entire page contents. If a link is
meaningless when read out of context, it makes the task of
navigating a web site very difficult. For example, a web page
may include the sentence "Click here for a text-only version of
the site" where only the words "Click here" are the hyperlink.
The link will be read by a screen reader as "click here" and the
user will have to locate the sentence in order to understand the
meaning of the link. The solution is to provide link titles
which make sense from a user's point of view without requiring
context to interpret.

- Problem: "Frames which are difficult to activate"
Frames can cause problems with some screen readers. It may be
difficult or impossible to reach some of the frames on a page.
If frames are used, a non-frames version of the site should also
be provided.

- Problem: "Some web sites have text lines wider than the screen
and my screen reader cannot cope with that"
When the contents of a web page are wider than the browser
window, sighted users can scroll horizontally to read the
information, although this represents poor usability. If part of
line of text is not visible in the browser window, some screen
readers will not read it aloud.

A similar problem occurs if the text area is specified using
"absolute" rather than "relative" sizing. If you are a sighted
user and you resize your browser window on some web sites, the
contents of the page seem to expand to fill the window. This
means that relative sizing has been used to specify the widths
of text columns as a percentage of the browser window size,
rather than defining them as a fixed or "absolute" width. In
other words, the column widths have been specified "relative" to
the browser window width. Font sizes can also be specified using
relative sizing. People who are uncomfortable with small fonts
can then increase the size, using standard browser controls.

- Problem: "The suspicion that there is a lot of information on
the screen but for some reason the screen reader will not read
it"
This is a general problem with web sites that do not indicate up
front what a screen contains. A sighted person can quickly see
what a screen contains by scanning it but a non-sighted person
has to rely on being able to read each item one by one. From
experience, they may suspect that the page contains a lot more
than they have been able to find.

The solution to this problem is to create simple designs where
each page has a particular coherent purpose which can be
explained in a title and a short introductory text.

What Sites and Services do Disabled People Use?
Disabled people use the same sites as non-disabled people.
Research by the Disability Statistics Center at the University
of California reveals that the most common reasons that people
with disabilities cite for using the Internet are email and
searching for information. These are also the two most common
reasons for people without disabilities. Large numbers of
disabled users also report accessing news, weather, sports
scores, online education, jobs, shopping and paying bills. [11]

We asked a number of visually impaired people in Ireland what
activities they visit web sites for. Their answers included the
following:

  * Downloading software
  * Research
  * Email
  * News & sports
  * Chat or discussion groups
  * Banking

This is similar to the answers you would get from any group of
web users.

Testing for Accessibility
There are a number of methods that web site designers can use to
ensure their web sites are accessible. Firstly, comprehensive
guidelines are available which, if followed, will ensure
accessibility. However, following the guidelines and detecting
violations is not always easy because some points require
subjective judgement. It is made easier by automatic testing
tools which check web pages against the accessibility guidelines
and report violations. Although these tools are very useful,
they are limited in the violations they can detect. Also,
interpreting their output and solving the problems requires
knowledge of HTML and accessibility issues. Therefore, expert
input is essential. An accessibility expert is someone who is
familiar with accessibility guidelines, the nature of
disabilities, assistive technologies used by disabled people,
and the technologies used to create web sites. Lastly, as with
usability in general, testing involving real users using
assistive technologies is indispensable.

Accessibility Guidelines
The Inter-Departmental Web Publication Group chaired by the
Department of the Taoiseach was set up in 1999 to prepare
guidelines and standards for public sector web sites. The Group
was set up to fulfil the commitment given in paragraph 42 of the
Government Action Plan: [1]

"42. Service-wide guidelines and practices will be adopted
regarding content format and presentation etc. for web sites,
and an Interdepartmental Group will be established to deal with
these issues."

Their first report, "aimed at webmasters and those involved in
or with influence over designing and setting up public sector
web sites" [2], provides some basic guidelines on usability and
accessibility. Public sector officials should therefore be
familiar with these guidelines.

However, to ensure accessibility, designers should follow the
detailed "Web Content Accessibility Guidelines" issued by the
Web Accessibility Initiative (WAI) [12]. The WAI is a working
group sponsored by the World Wide Web Consortium (W3C), an
independent, international body that creates Internet and
programming language standards. All its recommendations are
highly regarded and the WAI guidelines are currently accepted as
best practice in the industry. They provide in-depth technical
direction on HTML issues relating to accessibility but require a
working knowledge of HTML to interpret them.

The guidelines are divided into Priority 1, 2 and 3 checkpoints,
with Priority 1 being the most important. It is generally
considered that for a web site to be accessible it must pass at
least the Priority 1 checkpoints. An example is checkpoint 1.1
which states: "Provide a text equivalent for every non-text
element (e.g., via "alt", "longdesc", or in element content)".
Although the WAI guidelines are comprehensive and mostly very
detailed, many checkpoints require subjective interpretation. An
example is Checkpoint 14.1 which is also Priority 1 and states:
"Use the clearest and simplest language appropriate for a site's
content".

Automatic Testing Tools and the Bobby Test
To assist developers in assessing web sites for accessibility, a
number of automatic testing tools have been developed. The best
known and most comprehensive of these is called Bobby [13].
Similar tools include The Wave [14] and Lift [15].

Bobby is a piece of software that analyses web pages for
accessibility. It is a free service provided by CAST (Centre for
Applied Special Technology), a non-profit organization which
aims to expand opportunities for people with disabilities
through computer technology. Bobby's analysis of accessibility
is based on adherence to the WAI guidelines. To become "Bobby
approved", a web site must pass all of the automatically
testable Priority 1 WAI checkpoints.

Bobby deals with WAI checkpoints in one of three ways:

  * Those that relate to a specific type of screen element and
    for which violations can be detected automatically. Bobby
    can highlight these.
  * Those that relate to a specific type of screen element but
    for which violations cannot be detected automatically. These
    require manual checking and Bobby can tell you where to
    check.
  * Those that do not relate to a specific type of screen
    element. Bobby will only list these for reference because it
    cannot test for them.

WAI checkpoints for which violations can be detected
automatically include Checkpoint 1.1 (Priority 1) "Provide text
equivalent for every non-text element". All images and other
non-text elements can be detected and automatically checked to
see if they include alt text tags. If Bobby detects a violation
it will flag it and provide some guidelines on how to repair the
HTML code. However, Bobby cannot tell you whether the alt text
is relevant or useful.

WAI checkpoints for which violations cannot be detected
automatically include 14.3 (Priority 3) "Use header elements to
convey document structure and use them according to
specification". It is not possible for Bobby to know whether a
header element has been used to convey structure or whether it
has been misused to create a formatting effect. If Bobby detects
any header elements on a page it highlights the possibility that
the checkpoint has been violated and prompts you to make a
manual check at that point. However, it is not possible for
Bobby to detect pieces of text which are structurally used as
titles or headings but which have not been constructed as header
elements.

Checkpoints which do not relate to a specific type of screen
element include 3.5 (Priority 2) "Create a style of presentation
that is consistent across pages". Bobby cannot detect
inconsistency or tell you anything at all about presentation
style.

Because even some Priority 1 checkpoints are not amenable to
automatic compliance testing, it is not possible for Bobby or
any other automatic testing tool to ensure that a web site is
accessible according to the WAI definition. Because of its
limitations, the Bobby test does not guarantee that a site is
entirely accessible. If Bobby is the only test which is deployed
during development, it will still be possible to produce a site
which is inaccessible.

Expert Evaluation
Expert evaluation will identify problems that require informed
human judgement and that cannot therefore be detected by an
automated testing tool. An expert may use an automatic tool such
as Bobby as a starting point but will then carry out all the
suggested manual checks and assess the site against all the
remaining guidelines. However, checking the HTML is only the
start. An expert can assess a web site by taking a disabled
user's perspective and trying to carry out real tasks using
assistive technologies. For example, the expert may access the
site using a text-only browser such as Lynx [16].

Whilst a text-only browser does not faithfully recreate the
experience that a user with a disability will have, it provides
some insight for several reasons:

  * All graphic clues to a site's structure are removed. A
    text-only browser is quite different to a text-only web
    site. For example, there is no such thing as bold or italic
    text. Links that appear as images without alt text are
    difficult to place in context.
  * You can only view a small portion of a web page at a time
    and must therefore rely on memory to retain and compare
    information. Blind people rely heavily on memory. Also,
    people with cognitive disabilities may struggle with this
    problem.
  * Navigating web sites built with frames is difficult. Poorly
    designed frames cause navigation problems for blind people.

In addition, the expert may use keyboard-only navigation instead
of using a mouse which demands hand to eye co-ordination that
blind people or those with limited motor control do not have.
They may even use an audio browser or screen reader.

Expert evaluation by a usability professional is closer to a
real user's point of view than an automated test because the
expert looks at the interface a user encounters rather than the
HTML that creates it. It can identify many problems which
automatic testing tools cannot. For example, Bobby can tell you
if an image has alt text but it cannot tell you if the text is
meaningful. This is not to say that poor HTML does not cause
accessibility problems, but a web site can be accessible in so
far as it passes the Bobby test but may still be difficult for
someone with a disability to understand and use.

An added benefit of expert evaluation is that it can be carried
out on a system design before the HTML is created. This means
that problems can be identified and resolved much earlier in the
development process, where the cost and time required to fix
them is lowest.

However, although the expert evaluation gets closer to the user
experience, it does not replace testing a system with real
users. Usability testing with real users will always provide the
best information.

User testing
A usable web site must let the people who use it accomplish
their goals and tasks effectively and efficiently while working
in their own physical, social, and cultural environments.
Involving users in the design and testing process is the best
way to ensure that accessibility problems are recognised and
overcome.

A structured user test involves real users using the web site to
perform real tasks. It gathers insights into problems through a
combination of observation and user feedback. It identifies real
problems with information design, structure and content, visual
design and interactive features. User testing can be carried out
either on an existing web site or on prototypes during the
development process. Findings can be fed back into the process
to provide a clear direction for designers and developers.

If user input takes place early and often, the problem of
investing significant time and money in solutions that fail to
meet basic needs can be avoided.

Frontend e-Government Accessibility Analysis
We carried out an accessibility analysis of three prominent
Irish Government web sites. This involved running the Bobby test
and carrying out a task-based expert evaluation using a
text-only browser and an audio browser. The sites we analysed
were:
  * Revenue On-Line Services: http://www.revenue.ie/
  * Donegal County Council: www.donegal.ie/dcc
  * Department of the Taoiseach: www.irlgov.ie/taoiseach

The Revenue On-Line Services and the Department of the Taoiseach
are featured in the e-Government resources section of the REACH
agency which is charged with setting up an online 'one stop
shop' for government services [17]. Donegal County Council's web
site was chosen because the Taoiseach recently referred to the
Council as being:

".amongst the foremost local authorities in utilising
information systems in delivering services to their customers."
[18]

Our aims in carrying out this analysis were:

  * To provide real examples of accessibility problems which
    might be encountered by people with disabilities who might
    want to use online Irish government services.
  * To learn from the mistakes which were made on these sites.
  * To broadly compare the results and the insights provided by
    the Bobby test and an expert evaluation carried out by a
    team of usability professionals.

This analysis is not a criticism of the efforts made by people
in Government agencies who are responsible for the sites we
reviewed. Frontend acknowledges that the Government has stated a
commitment to accessibility and is presently taking the lead on
tackling this important usability issue. The private sector can
learn many valuable lessons from the achievements as well as the
failings of the online Government services. Also, it should be
noted that the sites discussed in our analysis may have changed
since the time we reviewed them. However, even if this is so, we
still find it useful to discuss these features, since our aim is
to provide examples of good and bad practice.

The analysis was done on the basis of a set of typical
information finding tasks which users of these sites may want to
perform. We restricted our analysis to those pages that a user
would have to visit in order to perform the tasks in the most
straightforward way. This analysis does not, therefore,
constitute an exhaustive evaluation by any means. Furthermore,
we are only presenting a few of our findings here as examples of
the kind of accessibility problems that disabled users actually
face.

Summary of findings
Here is a broad overview of what we learnt from our
accessibility analysis of these three sites.

According to Bobby, Donegal County Council and The Department of
the Taoiseach web sites are inaccessible. The text-only version
of the Revenue Commissioners passed the Bobby test, although the
graphic homepage, which is the main point of entry for the
text-only pages, failed.

The most common problems we identified were:

  * Images missing alt text
  * Poor alt text
  * Poor use of frames
  * Poor navigation - links out of context, difficulty for users
    to get an overview of the site's contents

The expert evaluation identified problems with all three sites,
including those pages which passed the Bobby test.

Analysis of Donegal County Council Web Site
We set out to complete the following task:

You live in Falcarragh and you want to join the library. There
is no local library but you have heard that the mobile library
comes to Falcarragh. Find out when and how often it calls.

Bobby failed this web site for failing to meet WAI Priority 1
accessibility criteria and also pointed to a failure to
"Identify the language of the text". Some speech synthesizers
and Braille devices can cope with different languages but they
must be told what language to work with. If "natural language"
changes are not identified, they may be indecipherable when
machine-spoken or brailled. Occasional words are not a major
problem but larger items such as paragraphs can cause
difficulties in this context.

Bobby also suggested a manual check: "Do not use pop-up windows
or change the active window unless the user is aware this is
happening". This message is triggered by a "mailto" link for the
site's webmaster. Clicking this link would pop up an email
window on top of the browser window. Creating or switching
windows without warning can easily confuse blind users if their
screen reader suddenly shifts focus from the web site to the new
window. In this case, the email window is not a serious problem,
as it is likely that most users have their systems configured to
cope with the mailto feature.

The expert evaluation found further problems. For example, the
home page does not provide an overview of the contents or
structure of the site. It uses frames for layout and the frame
titles, "navbar", "masthead" and "contentarea", do not
adequately describe the purpose of each frame or the information
they contain. If frames are used, their titles should help a
blind user to gain an overview of the structure of the site.

Note: These are only a few of the problems found with this site.
We present these examples to illustrate the kind of
accessibility problems that disabled users face and that can be
found using the Bobby test and further expert analysis.

Analysis of Department of the Taoiseach Web Site
We tried to complete two tasks on this web site:

Task 1: Read the latest report on Partnership 2000.

Task 1: Find out the name and email address of the Minister for
Justice Equality and Law Reform.

Bobby failed this web site for failing to meet WAI Priority 1
accessibility criteria and also pointed to a priority three
problem "Separate adjacent links with more than white space".

The "Publications" page is a long list of text links. Blind
users sometimes have difficulty differentiating text content
from text links. Whereas a sighted person can identify links
from visual clues, such as colour or underlines, a blind user
may use their screen reader to call up a list of the links on
page. If adjacent links are not separated by text or an image,
even if they occur on consecutive lines, some screen readers
will incorrectly read them as a single link.

The expert evaluation found confusing and meaningless
information on the homepage, which was caused by either
providing poor alt text with images, or none at all. For
example, no alt text is provided on two images so the screen
reader reports only the image file names, "dot.gif" and
"irllogo.gif". Where it exists, alt text does not always
correspond to the text content associated with images. For
example, a graphical "FAQ" button on the homepage has the text
explanation "Frequently Asked Questions" beside it, but the alt
text reads "Frequently Requested Information". These could be
interpreted as being two different things.

Note: These are only a few of the problems found with this site.
We present these examples to illustrate the kind of
accessibility problems that disabled users face and that can be
found using the Bobby test and further expert analysis.

Analysis of the Revenue Commissioners Web Site
We carried out these two tasks on the Revenue Commissioners web
site:

Task 1: You are a PAYE taxpayer. You are also blind. Find out
your rate of income tax and any allowances you are entitled to.

Task 2: Following on from the above, you want to make further
enquiries. Find the telephone number and email address of your
local PAYE office.

This web site features a text-only version to facilitate
accessibility. The text-only pages passed the Bobby test but the
graphic homepage, which is the entry point for all users, failed
to meet WAI Priority 1 compliance.

Bobby highlighted a WAI Priority 2 problem: "Do not use the same
link phrase more than once when the links point to different
URLs". Towards the top of the text-only homepage, a link called
"services" takes the user to another list of links further down
the same page. This list features another link, which is also
called "services". Following this second link takes the user to
another page, within the services section of the web site. When
two links point to different places they should use different
titles, to clarify navigation.

The expert evaluation found problems on the graphic homepage.
The link to access the text-only site reads "Click here for a
text-only version of the site". The word 'here' is the hyperlink
but is meaningless when read out of context and would hinder
access to the text-only version for someone using a screen
reader.

Note: These are only a few of the problems found with this site.
We present these examples to illustrate the kind of
accessibility problems that disabled users face and that can be
found using the Bobby test and further expert analysis.

Good Usability is Good Accessibility
Achieving universal accessibility is part way towards the goal
of achieving universal usability. Accessibility problems are
those that make it more difficult for a disabled person to use
an application or service than for a non-disabled person. They
discriminate between users. However, an "accessible" web site
may still have serious usability problems that make it equally
difficult for any person, disabled or non-disabled, to use the
site for its intended purpose. Usability focuses on making
software applications and services easy for all people to use,
so good usability practices are also good accessibility
practices.

The remainder of this section provides a brief discussion of the
activities necessary for achieving usability.

Understand User Requirements
The first step in understanding user requirements is to identify
the target audiences and the nature of the common tasks they may
wish to perform. Development is then focused on addressing the
right audience and facilitating the tasks they need to complete.
Proper audience and task analysis is an essential element in
user-centred design and should ideally occur before system
design or programming activities. It involves talking to current
and potential users and, wherever possible, observing them using
the service.

Focus on Common Tasks
An interface must take into account common tasks and focus on
enabling users to complete them quickly and easily. Interface
design that prioritises and highlights alternative routes to
completing common tasks will enable different types of users to
achieve their goals in a way that suits their needs.

Support the User
An effective interface supports users by providing a variety of
prompts and a frame of reference which builds awareness of their
current position and available options. This helps them through
tasks and processes and facilitates understanding of the
interface structure.

Maintain Consistency
Users will develop familiarity and efficiency in using an
interface if they are able to learn over time how the interface
works and the conventions upon which it is built. Consistency is
therefore vital, not just graphically but also in the way the
interface works.

Provide Regular Feedback
Clear confirmation that an action has either succeeded or failed
helps build trust and confidence. Likewise, waiting time should
be accompanied by progress indicators.

Meet User Expectations
Users must trust an interface before they are comfortable enough
to work quickly with it. Users must believe that each action
causes the expected result to develop trust. Having the ability
to undo actions also builds confidence in the interface.

Ensure Interfaces are Versatile
Users appreciate a choice of techniques when navigating an
interface. As often as possible users should be able to choose
input methods, i.e., keyboard or mouse. Provide alternative
routes to allow users of different abilities or with different
needs to complete common tasks.

Test!
Carry out user testing as often as possible during development.
Users provide feedback that can often be missed by even the most
informed expert opinion. The results from empirical and
observational user testing can be used to optimise the final
interface design.

Summary: What You Need to Do
Accessibility is a usability issue. Make a commitment to
investing in usability and accessibility. Your investment will
produce a measurable return by delivering a better service to
your customers and reducing development times and costs in the
long run, while reaching a larger audience. The sooner you
introduce good usability and accessibility practice, the greater
the saving on repairs or "retro-fitting" a web site to make it
accessible. Database-driven web sites in particular can grow at
a tremendous rate, as it is easy to add content on a regular
basis. If this is not accessible, the problems and costs of
repair are compounded. Investing in usability and accessibility
will reduce the likelihood of suffering potentially expensive
legal actions which may also damage your profile.

Frontend hopes this document has been helpful in providing a
first step towards making your online services more usable in a
general sense and especially so for people with disabilities.
You can find more information relating to these topics at the
Frontend Usability Infocentre, an online resource, which is
available at www.frontend.com/usability_infocentre.

You can also take the following actions to optimise usability
and accessibility.

If You Already Have a Web Site
Use the Bobby test to get a quick impression of accessibility
and find some of the important problem areas. However, do not
assume that your site is accessible just because it passes this
test.

Organise an accessibility audit. The best way to do this is to
have experts carry out a structured user test with real users
or, if time and other resources are limited, a thorough expert
evaluation. Use the feedback to create an accessibility
development plan.

Ensure that accessibility is a priority for web site maintenance
in order to avoid undoing previous efforts. For example, if you
change a photo of a staff member, make sure to replace the alt
text as well.

If You are Planning to Develop or Extend a Web Site
Measurable accessibility targets should be specified as a
requirement in web development briefs, including tender
requests.

You should have a basic knowledge, or at least be familiar with
the WAI WC3 accessibility guidelines and the Report of the
Inter-Departmental Web Publication Group.

Ensure that your web site developers and web site maintenance
personnel have a working knowledge of these guidelines. You
should stipulate that your new site achieves at least priority 1
and ideally priority 2 compliance with the latest version of the
guidelines. Ensure that your developers use Bobby, or some other
WC3 endorsed HTML validator to produce HTML which achieves at
least priority 1 compliance. Specify this criteria in your web
development brief, including tender documents.

The best practice is to pursue an inclusive development process.
Involve users who are representative of your target audience
from the onset of your project. Include people with disabilities
as well as those without.

Involve real users in the requirements gathering stage and carry
out usability testing at key moments in development. Doing so
will not only deliver a more usable web site, it will save time
and money in the long run. It is more costly and time consuming
to repair a web site in order to make it accessible than to
develop an accessible web site from scratch.


Frontend - Usability Engineering & Interface Design

Dublin (HQ)
40 Westland Row
Dublin 2
Ireland
Tel: +353 1 2411600
Fax: +353 1 2411601    London
16 Mountford House
25 Britton Street
London EC1M 5NY
Tel: +44 207 6082971
Fax: +44 797 4151362

Email: mail@frontend.com

----------
End of Document






